The world is comprised of a wide and varied assortment of environments and subsystems. Many environments present challenges to sufficiently accurate modeling. A microcosm of this problem occurs in many enterprise architectures. These enterprise architectures may be intended to have a wide variety of uses: disseminating information about goods and services offered through a site on the World Wide Web, achieving objectives related to a business concern, providing a programming infrastructure for development of software, or keeping track of sales and sales force information.
Consequently, these enterprise architectures grow organically, sewn together in a Frankenstinian manner from a variety of heterogeneous machines and applications. Predicting the effects of business initiatives process and organization, the interaction of applications, infrastructure and data organization within an IT environment, etc., on these enterprise architectures is almost an exercise in futility without some sort of model. However, modeling these types of environments is a daunting prospect.
Typically, there are two approaches to creating models for enterprise architectures. The first is to create a diagram or a spreadsheet based inventory of the items of interest. This approach is problematic, as creating these models requires an in depth evaluation of an enterprise architecture and manual creation of the documents, and whole document retention systems must be kept in place to version and store the documents associated with these types of models. Additionally, changes to the enterprise architecture wreak havoc on these models. The effects from these changes must be manually traced through each of the diagrams, which are not only particularly prone to errors, but time consuming as well. Other problems with storing these models in documents include that there may be a large number of users who need to be able to access and modify these documents and documents of this type don't lend themselves to concurrent modification, and that it is very difficult to cross-reference information across these documents.
The second approach, equally problematic, is to store items of interest of an enterprise architecture in a relational database. Models created with a relational database, however, are particularly susceptible to changes in the enterprise architecture itself. Adding layers, applications, dependencies, projects, geographical locations, etc., to an enterprise architecture may require changes to a table schema implementing the model, which may in turn entail revising all the SQL statements used to implement the database. Furthermore, as enterprises tend to be heterogeneous, importing data to populate such databases may be difficult, as the data may be contained in a large number of disparate and heterogeneous repositories (if, indeed, such data exists at all).
As can be seen then, it may be extremely difficult to both create a data model for an enterprise architecture and to actually populate that data model with data. A microcosm of these problems occurs with respect to calculating a metric of interest with respect to these enterprise architectures. For example, one metric of interest may be the cost of an asset. The cost of an asset within an enterprise architecture may go beyond the direct cost of purchasing and maintaining that asset. In many cases, the true cost of an asset depends on the cost of the infrastructure and other resources needed to actually support or implement that asset. In other words, the total cost of a single asset may include the cost of portions of other assets, and the cost of those assets may depend on still other assets. Consequently, the actual cost of an asset may encompass both direct and indirect costs.
With the heterogeneity of enterprise architectures and the difficulty of creating accurate models of these enterprise architectures comes the related problem of data completeness. The calculation of a metric of interest using a data model of an enterprise architecture can only be as accurate as the data in the data model used to calculate the metric of interest. As discussed above, however, in many cases it may be difficult to populate such a data model with data. The sparseness of data in a data model may thus impact the ability to calculate a metric, or the accuracy of any metric calculated from such data.
As can be seen, a need exists for methods and systems for a generic data model which can model a complex enterprise architecture, and which is easily extensible to allow the representation of any desired logical or physical entity and the associations and dependencies between these entities. Furthermore, a need exists for methods and systems which can use these data models to calculate a metric of interest with respect to a modeled enterprise architecture and also calculate an associated measure of data completeness as an indication of such metrics.